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Description 

Field Of The Invention 

5 [0001] This invention relates to teleservice messaging in a wireless communication network. More particularly, the 
invention concerns a system and method for providing an indication of maximum teleservice payload size to a tele- 
service message sending entity in order to avoid resegmentation and retransmission delays. 

Description Of The Prior Art 

10 

[0002] Teleservice messaging! is a form of communication that allows information payloads (e.g. displayable text, 
graphics, executables, etc.) to be sent to mobile wireless communication devices (e.g., cellular telephones) in man- 
ageable form. This type of messaging can be found in many species of wireless telecommunication systems, including 
those designed according to the TIA/EI A-41 -D standard, the IS-2000 standard, the GSM standard, the UMTS standard, 
the IMT-2000 standard, and others. When a Mobile Station (MS), such as a wireless telephone, a wireless Personal 
Digital Assistant (PDA) or any other device capable of disseminating teleservice messages, is sent teleservice mes- 
sages containing a payload by a network sending entity, such as a Short Message Service (SMS) Center (SMSC), a 
Message Center (MC), a Wireless Application Protocol (WAP) Server, or any other content provider, no regard is given 
to payload size constraints of the network receiving entities that serve the MS, such as the Mobile Switching Center 

20 (MSC), the Base Station (BS), or other entities. If one (or more) of the network receiving entities cannot handle the 
payload size, the network sending entity must be informed of the problem, and it must then resegment the payload\ 
into smaller information units and resend them. This causes delay and needlessly ties up network resources. 
[0003] Accordingly, a solution to the forgoing problem is required that enables teleservice payloads to always be 
sent in information unit sizes that can be accommodated by network receiving entities, such that message resegmen- \ 

25 tation and retransmission due to excessive payload size are avoided. 

Summary Of The Invention 

[0004] The foregoing problems are solved and an advance in the art is obtained by a novel system and method for 

30 providing improved teleservice messaging to a mobile station in a wireless communication network. In accordance 
with the invention, an indication is provided to a network sending entity of the maximum teleservice payload size that 
can be sent by the network sending entity to the mobile station via network receiving entities serving the mobile station. 
The payload size indication is utilized by the network sending entity to format the size of teleservice messages sent 
by the network sending entity to the mobile station via the network receiving entities, such that resegmentation and 

35 retransmission are avoided. 

[0005] Network sending entities (e.g. SMSCs, MCs, WAP servers, etc.) that send teleservice layer messages con- 
taining a payload (e.g., displayable text such as SMS messages, displayable text and graphics such as WML (WAP 
Markup Language) documents, and executables such as WAP Java applets, etc.) can thus be advised of the maximum 
payload size (e.g., in bits, bytes, data units, etc.) that can be handled by network receiving entities in the wireless 

40 network that serve a mobile station (e.g., MSCs, BSs, etc.), on a per message basis. This information is used by the 
network sending entity to appropriately segment the total payload into manageable packages (at the teleservice layer) 
prior to sending them on to the network receiving entities. This enables efficient use of transmission media and avoids 
retransmissions of correctly sized packages which otherwise may need to be done by trial and error. 
[0006] In preferred embodiments of the invention, the payload size indication is provided from one of the network 

45 receiving entities to the network sending entity. Most preferably, the payload size indication is provided from one of the 
network receiving entities to the sending network entity via a database associated with the mobile station. The receiving 
network entity providing the payload size indication could be an MSC acting as a voice communication switch on behalf 
of the mobile station. If data communication is involved, the receiving network entity sending the payload size indication 
could be a Mobile Data Intermediate System (MDIS) or a Serving GPRS Support Node (SGSN). The database could 

so be the mobile stations Home Location Register (HLR). 

[0007] The payload size indication is preferably provided from one of the network receiving entities to the database 
as a message parameter during standard registration message exchange between the network receiving entity and 
the database during operations of the wireless network. Similarly, the payload size indication is preferably provided 
from the database to the network sending entity as a message parameter during routine registration message exchange 

55 between the database and the network sending entity. 
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Brief Description Of The Drawing 

[0008] The foregoing and other features and advantages of the invention will be apparent from the following more 
particular description of preferred embodiments of the invention, as illustrated in the accompanying Drawing, in which: 

5 

Fig. 1 is a functional block diagram showing a wireless communication system constructed in accordance with the 
invention; 

Fig. 2 is an information flow diagram showing an Authentication Request operation using a maximum teleservice 
io payload size indicator in accordance with the invention; 

Fig. 3 is an information flow diagram showing a FeatureRequest operation using a maximum teleservice payload 
size indicator in accordance with the invention; 

*5 Fig. 4 is an information flow diagram showing a Location Request operation using a maximum teleservice payload 

size indicator in accordance with the invention; 

Fig. 5 is an information flow diagram showing an Origination Request operation using a maximum teleservice pay- 
load size indicator in accordance with the invention; 

20 

Fig. 6 is an information flow diagram showing a QualificationRequest operation using a maximum teleservice pay- 
load size indicator in accordance with the invention; 

Fig. 7 is an information flow diagram showing a Registration Notification operation using a maximum teleservice 
25 payload size indicator in accordance with the invention; 

Fig. 8 is an information flow diagram showing an SMSNotification operation using a maximum teleservice payload 
size indicator in accordance with the invention; 

30 Fig. 9 is an information flow diagram showing an SMSRequest operation using a maximum teleservice payload 

size indicator in accordance with the invention; and 

Fig. 1 0 is an information flow diagram showing aTransferToNumberRequest operation using a maximum teleserv- 
ice payload size indicator in accordance with the invention. 

35 

Detailed Description Of The Preferred Embodiment 

[0009] Turning now to the figures, wherein like reference numerals represent like elements in all of the several views, 
Fig. 1 illustrates a functional representation of an exemplary wireless communication system 2 constructed in accord- 

40 ance with preferred embodiments of the invention. Fig. 1 is intended to be generic in nature and not limited to any 
particular wireless network standard. Indeed, the wireless system 2 may be implemented using any of the wireless 
network standards now in existence, such as TIA/EIA-41-D, IS-2000 or GSM, or which may be adapted in the future, 
such as UMTS, IMT-2000 or the like. Moreover, as described below, the wireless system 2 may be adapted to carry 
voice traffic, data traffic or both . 

45 [0010] As is known in the art, the wireless system 2 includes a plurality of wireless service areas, each of which is 
managed by the usual wireless network serving entities, including an MSC and one or more BSs. Fig. 1 illustrates two 
wireless service areas that are respectively managed by the MSC 4 and the MSC 6. Associated with each MSC are 
the usual Home Location Register (HLR), Visitor Location Register (VLR), Authorization Center (AC) and Equipment 
Identity Register (EIR), all of which, with the exception of the invention-related enhancements described below, are 

so conventional in nature. In Fig. 1 , it will be seen that the MSC 4 is associated with an HLR 8, a VLR 1 0, an AC 1 2 and 
an EIR 14, and that the MSC 6 is associated with an HLR 9, a VLR 11 , an AC 13 and a EIR 15. 
[0011] As is further known in the art, each MSC supports a plurality of BSs, each of which conducts wireless com- 
munications in an assigned geographic coverage area commonly referred to as a ceil. Fig. 1 illustrates two such BSs; 
namely, the BS 1 6 connected to the MSC 4 and the BS 1 8 connected to the MSC 6. Each BS includes radio transceiver 

55 equipment for communicating in conventional fashion over an air interface with a plurality of MSs, which could be 
cellular telephones, wireless computing devices such as PDAs, or other radio communication equipment. Fig. 1 illus- 
trates two such MSs; namely, the MS 20 communicating with the BS 1 6 and the MS 22 communicating with the BS 1 8. 
[0012] In the wireless network 2, the MSCs 4 and 6 act as switching nodes for respectively communicating voice 
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traffic on behalf of the MSs 20 and 22 over the circuit-switched PSTN 23. In association with the usual data network 
gateway equipment (not shown) the MSCs 4 and 6 may also communicate voice traffic (VoIP) over the public Internet 
31 . The wireless network 2 may also be adapted to carry data traffic (e.g., over the Internet 31 ) on behalf of MSs that 
are equipped for wireless data communication There are several wireless data standards in use today, with the most 

s prevalent being the Cellular Digital Packet Data (CDPD) and General Packet Radio Service (GPRS) standards. 

[0013] The wireless network 2 can be adapted to implement the CDPD standard by adding a plurality of Mobile Data 
Base Stations (MDBSs) and a Mobile Data Intermediate System switch (MDIS) in one or more of the wireless service 
areas. These entities are analogous to, and are typically associated with, the existing voice-oriented BSs and MSCs. 
The MDBSs communicate with the MSs over an air interface and the MDISs provide connectivity to a data network, 

10 such as the Internet 31 . Thus, in Fig. 1 , the wireless network 2 may include an MDBS 24 associated with the BS 16, 
and an MDBS 26 associated with the BS 18. Likewise, the wireless network 2 may include an MDIS 28 associated 
with the MSC 4 and an MDIS 30 associated with the MSC 6, each of which connect to the Internet 31 . In combination, 
the MDBS 24 and the MDIS 28 provide data communication support on behalf of the MS 20, while the MDBS 26 and 
the MDIS 30 provide data communication support on behalf of the MS 22. The wireless network 2 can be adapted to 
implement the GPRS standard by adding a plurality of Serving GPRS Support Nodes (SGSNs) and a Gateway GPRS 
Support Node (GGSN) in one or more wireless service areas. Each SGSN is typical fy connected to a voice-oriented 
or packet data-oriented BS and MSC, and each GGSN is usually connected to a data network, such as the Internet 
31 . Thus, in Fig. 1 , the wireless network 2 may include an SGSN 32 and GGSN 34 associated with the wireless service 
area managed by the MSC 4, and an SGSN 36 and GGSN 38 associated with the wireless service area managed by 

20 the MSC 6. In combination, the SGSN 32 and the GGSN 34 provide data communication support on behalf of the MS 
20, while the SGSN 36 and the GGSN 38 provide data communication support on behalf of the MS 22. 
[0014] As is conventional, the MSs 20 and 22 have teleservice messaging capability, which allows them to retrieve 
teleservice payloads from a Network Sending Entity (NSE) 40 that communicates with the MSs via receiving network 
entities in the wireless network 2, such as the MSCs and the BSs. The NSE 40 could be any network sending entity 

25 supporting any service that requires the sending of large blocks of information requiring segmentation in order to be 
delivered to the MSs. For example, the teleservice messages sent by the NSE 40 could include SMS messages, 
Unstructured Supplementary Service Data (USSD) messages, Circuit Switched Data (CSD) messages, CDPD mes- 
sages and GPRS messages. More specifically, one kind of network sending entity that could be represented by the 
NSE 40 is an SMS Message Service Center (SMSC) sending SMS messages. An SMSC acting on behalf of the MSs 

30 20 and 22 could provide teleservice messages to the MSs that pertain to communications received from the PSTN 23 
(e.g., voice mail messages), the Internet 31 (e.g., email messages), and/or from other sources, such as a paging 
network 42 (e.g., paging messages). These messages would typically be provided to the MSs 20 and 22 via the intel- 
ligent network (e.g., SS7) portion 44 of the PSTN 23. Another network sending entity that could be represented by the 
NSE 40 is an Over-The-Air-Function (OTAF) used for provisioning wireless service (e.g., activating subscribers), down- 

35 loading Preferred Roaming Lists (indicating the systems from which a reamer would prefer to receive service), and 
other functions Still another network sending entity that could be represented by the NSE 40 is a WAP server operating 
in accordance with the WAP standard. 

[0015] In general, the network receiving entities that serve the MSs will vary depending on the message source and 
type. Circuit-based teleservice layer messages would normally be distributed to the MSs through the MSCs and the 
40 BSs. Packet-based teleservice layer messages may be distributed to the MSs through the MDISs (for CDPD data), or 
the SGSNs (for GPRS data), together with the BSs. 

[0016] As stated, the network sending entities used in prior art wireless network systems format teleservice layer 
messages without knowledge of payload size constraints in the network receiving entities serving the mobile stations. 
The solution provided in accordance with preferred embodiments of the present invention entails the inclusion of an 

45 attribute in standard wireless network registration messages (e.g., a RegistrationNotification message according to 
the TIA/EIA-41 -D standard) that allows the network sending entity to determine the maximum teleservice payload size 
that can be handled by the receiving network entities (e.g., MSCs, BSs, etc.). These standard registration messages 
that are modified to incorporate a teleservice payload size attribute include (1) registration messages that are first 
exchanged between a network receiving entity serving an mobile station (e.g., an MSC) and a database associated 

so with the mobile station (e.g., an HLR), and (2) registration messages that are thereafter exchanged between the da- 
tabase and the network sending entity. More particularly, the first group of registration messages provide the teleservice 
payload size information from the serving network receiving entity to the database, where the information is stored, 
and the second group of registration messages provide the teleservice payload size information from the database to 
the network sending entity. The network sending entity will then be able to use this information on large messages in 

55 order to segment them into units of appropriate size. 

[0017] To illustrate, consider the wireless telecommunication system of Fig. I wherein network entities, such as the 
MC 32, an MSC 4 or 6, a BS 16 or 18, and an HLR 8 or 9 (among others) are involved in providing voice services to 
a network subscriber operating one of the MSs 20 or 22. In that case, when the subscriber powers-on the MS, roams 
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to a new service area (MSC/BS), originates a call, responds to a page for an incoming call, or in any other way accesses 
the wireless network 2, a registration process typically ensues. Registration results in the serving MSC informing the 
MLR assigned to the MS of the MS's presence in its sphere of influence. The HLR retains this information and will in 
turn forward the information upon request to the MC 32, so that the MC can forward incoming messages to the target 

s MS 20 or 22, as in the case of mobile-terminated SMS. 

[0018] Following are specific examples illustrating how teleservice payload size information can be provided to an 
NSE. All of the examples below are based on conventional registration messages currently in use according to the 
TIA/EIA-41-D wireless network intersystem operators standard. Appended to certain of these messages is a 
TS_DataSize parameter that indicates the maximum teleservice payload size that can be handled in a wireless service 

10 area managed by an MSC, an MDIS or a GGSN. Advantageously, no special payload size queries or processing are 
required. The teleservice payload size information, which is equipment-specific, can be input at system deployment 
time by a system administrator into a parameter database of the type conventionally associated with MSCs, MDIS and 
GGSNs for storing basic operating information. 

[001 9] In the following examples, the set of parameters shown in addition to the TS_DataSize attribute are not nec- 
15 essarily inclusive. They are set forth for the purpose of illustration only based on existing standards. Persons skilled 
in the art will appreciate that the parameters shown may be augmented (or altered) in the future. 

Example 1 — Authentication On Initial Access 

20 [0020] This operation scenario describes the successful use of an Authentication Request operation to authenticate 
an MS, which is attempting initial access to a serving MSC. The MS is aware that authentication is required on all 
system accesses. The result of the operation is to allow access. As shown in Step "a" of Fig. 2, during the initial access 
attempt by the authentication-capable MS (not shown), the serving MSC 50 sends an AUTHREQ message to a serving 
VLR 52. This message contains the following parameters, all of which are conventional save for the TS_DataSize 

25 parameter, which is added in accordance with the invention: 



35 



Parameters 


Usage 


Type 


AuthReqParametersI: 


Set of parameters in AUTHREQ: 




[MIN] 


Served MS MIN. 


R 


[ESN] 


Served MS ESN. 


R 


[MSCID] 


Serving MSC MSCID. 


R 


[PC.SSN] 


Serving MSC PC_SSN. Include if SS7 


O 




carriage services are used. 




[SystemCapabilities] 


Authentication capabilities of Serving MSC. 


R 


[SystemAccessType] 


Type of system access = registration. 


R 


UerminalType] 


Identifies the radio frequency interface 


R 




standard supported by the associated MS 




RAND] 


Random number derived from MS-provided RANDC by Serving MSC. 


R 


AUTHR] 


Authentication result provided by MS. 


R 


COUNT] 


Value of CallHistoryCount provided by MS. 


R 


TS DataSize] 


Maximum size of Teleservice payload 


O 



[0021] As shown in Step n b m of Fig. 2, the VLR 52 sends an AUTHREQ message to an HLR 54 associated with the 
MS. The parameters are the same as in Step "a" of Fig 2, but include the following conventional modifications: 



Parameters 


Usage 


Type 


[SystemCapabilities] 
[PC_SSN] 


Authentication capabilities of Serving VLR. 

Serving VLR PC_SSN. Include if SS7 carriage services are used. 


R 
O 



[0022] As shown in Step "c" of Fig. 2, the HLR 54 forwards the AUTHREQ message to an AC 56 associated with 
the MS. The parameters are the same as in Step "b" of Fig. 2. 

[0023] In Step "d" of Fig. 2, the AC 56 determines that the MS should be allowed access and sends an authreq 
message to the HLR 54. The message parameters, all of which are conventional, are as follows: 
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Parameters 


Usage 


Type 


5 


Auth Req Parameters2 : 
[CallHistoryCount] 


Set of parameters in auth req: 

Event counter used fordone detection. 

Included if SSD is shared. 


0 


10 


[RANDSSD] 


Random number for SSD generation. 
Included if a SSD update and a Unique 
Challenge to the MS should be initiated 
by the serving system. 


O 


15 


[RANDU] 


Random number generated by AC to 
produce AUTHU. Included if a Unique 
Challenge to the MS should be initiated 
by the serving system. 


O 


20 


[AUTHU] 


Expected MS response to Unique 
Challenge Order as calculated by AC. 

Inplnrtf*ri if n I InimiP fthnllf*nnA to tho 

iiiviuucu ii a uiiiuug \si iaiic;i iud iu liic 

MS should be initiated by the serving 
system. 


O 


25 


[UpdateCount] 


Indicates that the COUNT update 
procedure should be initiated by the 
serving system. 


O 


30 


NewSSDInfo: 


New SSD information: 






[Authentication- 
Algorithm Version] 


Include if SSD included to select 
authentication algorithm other than 
default. 


0 


35 
40 


[SSD] 


New value of VLR and AC shared secret 
data. May be included if the 
SystemCapabilities of the VLR include 
"CAVE execution" and AC 
administration policies allow distribution 
of the SSD. 


o 




NOSSD 


Indicates that previously provided SSD is no 
longer valid and should be discarded 


o 



45 

[0024] In step "e" of Fig. 2, the HLR 54 forwards the authreq message to the VLR 56 The parameters are the same 
as for step "d" of Fig. 2. 

[0025] In step T of Fig. 2, the serving VLR forwards the authreq message to the MSC 50. The parameters are the 
same as in step d of Fig. 2, except that the SSD, AAV and NOSSD parameters are not included, as is conventional. 

50 

Example 2 - Direct FeatureRequest With Call Routing 

[0026] This operation scenario describes a normal FeatureRequest operation when the response from an HLR in- 
cludes instructions for the serving system to set up a call. As shown in step "a" of Fig. 3, a feature code string (i.e., a 
55 string of digits including a feature code) received from an d MS (not shown) are included in a FEATREQ message and 
sent by a serving MSC 60 to an HLR 62 associated with the MS. The message parameters, which are otherwise 
conventional, include a TS_DataSize parameter in accordance with the invention, as follows: 
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Parameters 


Usage 


Type 


MIN] 


Served MS MIN. 


R 


ESN] 


Served MS ESN. 


R 


BILL ID] 


Call ID. Used for billing and redirection purposes when FEATREQ res u Us in call routing. 


R 


DGTSDIAL] 


Feature code string entered by served MS. 


R 


SENDERIN] 


Identification number of the sending node. 


R 


TRANSCAP] 


Indicates the serving system's transaction capability at the current time. 


R 


OTFI] 


Indicates the current feature activation status. 


O 


TS DataSize] 


Maximum size of Teleservice pay load 


0 



[0027] In step °b" of Fig. 3, the HLR 62 determines the appropriate feature treatment based on the received infor- 
mation and returns this in a featreq message. In this scenario, the response from the HLR 62 includes instructions for 
the serving system to set up the call. The featreq message has the following conventional parameters: 



20 


Parameters 


Usage 


Type 




FEATRESULT] 


Feature request result. 


R 




TERMLIST] 


Call termination information. 


R 


25 


ACTCODE] 


Treatment for served MS. If not included, treatment is based on 
FEATRESULT value. 


O 




AMMI IQT1 
MINrMLIO 1 J 


list, or tones or announcemenis 10 piay. it 
not included, announcement is based on 
FEATRESULT value. 


\J 


30 


DMHData: 
[DMH_AccountCode-Digits] 


Data for DMH recording purposes: 
Include if applicable. 


o 


35 


[DMH_AfternateBillingDigits] 


Include if applicable. 


o 


[DMH_BillingDigrts] 


Include if applicable. 


o 


40 


[MobileDirectory-Number] 


Include if applicable. 


o 


GRPINFO] 


Information associated with group routing. 


o 




OTFI 


Indicates the current feature activation status. 


o 




PACAIND] 


Indicates PACA priority level. 


0 


45 


CARDGTSJ 


Calling subscriber's PIC. Include if 
applicable and if not specified within the 
Termination List parameter. 


o 


50 


ROUTDGTS] 


Special routing instructions. Include if applicable and if not specified 
within the Termination List parameter. 


o 




TERMTRIG] 


Indicates active termination trigger points. 


o 



Example 3 - Successful Location Request 



[0028] This operation scenario describes a Location Request operation when the call treatment is to route the call to 
a PSTN directory number. As shown in step "a" of Fig. 4, an originating MSC 70 sends a LOCREQ message to an 
HLR 72 associated with the MS (not shown). This association is made through the dialed MS address digits (which 
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may not be the MIN). The message parameters, which are otherwise conventional, include a TS_DataSize parameter 
in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


BILLID] 


Call ID. Used for billing and redirection purposes when LOCREQ results in call 
routing. 


R 


OngID: 


Originating MSC's identification information: 




[MSCID] 


Originating MSC MSCID. 


R 


[PC_SSN] 


Originating MSC PC_SSN. Include if SS7 carriage services are used. 


O 


SystemMyTypeCode] 


Originating MSC vendor identification. 


MBC 


DGTSDIAL] 


Digits identifying called party. 


R 


TRANSCAP] 


Indicates the originating system's transaction capability at the current time. 


0 


TAT 


TerminationAccessType identifying special access situations. Include if 
applicable. 


O 


TS DataStzel 


Maximum size of Teleservlce pavload 


0 









25 [0029] In step "b" of Fig. 4, the HLR 72 determines that the call shall be routed to a PSTN directory number and 
returns this information to the Originating MSC in the locreq message, having the following conventional parameters: 





Parameters 


Usage 


Type 


30 


MIN] 


Called MS MIN. 


R 




ESN] 


Called MS ESN. 


R 




MSCID] 


Serving MSC's MSCID. 


R 


35 


ANN LIST] 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


O 




PSTNRoutinglnfo: 


Call routing information: 




40 


[TerminationList] 


Network termination information. 
Include if TerminationList is allowed. 


O 


45 


[Digits(Destination)] 


PSTN DN for use in call routing. Include 
if TerminationList is not allowed. 


0 




[RoutingDigits] 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


O 


50 


[Digits(Canier)] 


Called subscriber's PtC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


o 


55 


DM H Data: 


Data for DMH recording purposes: 






[DMH_AccountCode-Digits] 


Include if applicable. 


o 
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(continued) 



Parameters 


Usage 


Type 


[DMH_AlternateBillingDigits] 


Include if applicable. 


O 


[DMH_BittingDigrts] 


Include if applicable. 


O 


[MobileDirectory-Number] 


Include if applicable. 


O 


[DMH_Redirection-lndlcator] 


Include if applicable. 


R 



Example 4 - Successful Origination Request 

15 

[0030] This operation scenario describes an Origination Request operation when a call origination request is suc- 
cessful. As shown in step "a" of Fig. 5, dialed digits are included in an ORREQ message and sent by a serving MSC 
80 to an HLR 82 associated with an MS (not shown). The message parameters, which are otherwise conventional, 
include a TS_DataSize parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


BILLID 


Call ID. Used for billing and redirection purposes when ORREQ results in call routing. 


R 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCID 


Serving MSC MSCID. 


R 


PC_SSN 


Serving MSC PC_SSN. Include if SS7 carriage services are used. 


O 


DGTSDIAL 


Digits, entered by served MS, which identify the called party. 


R 


ORIGTRIG 


Indicates the origination trigger responsible for the operation invocation. 


R 


TRANSCAP 


Indicates the Serving MSC's transaction capabilities at the current time. 


R 


TS DataSize 


Maximum size of Teleservice payload 


O 



[0031] The HLR 82 determines that the origination request be approved and returns routing instructions in the orreqeq 
message, containing the following conventional parameters: 



40 


Parameters 


Usage 


Type 




TERMTRIG 


Termination trigger points currently active for the MS. Include if applicable. 


O 




ACTCODE 


Include if action to be performed is not implied through presence of other 
parameters. 


O 


45 


ANNLIST 


List of tones or announcements to play. If not included, announcement is based 
on other parameters in response. 


O 


50 


Routing! nfo: 
(TerminationList] 
[RoutingDigits] 


Call routing information: 
Call termination information. 
Special routing instructions. Include if 

applicable and if not specified within the 

TerminationList parameter. 


R 
O 


55 


[CarrierDigits] 


Calling subscriber's PIC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


O 




DM H Data: 


Data for DMH recording purposes: 
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(continued) 



Parameters 


Usage 


Type 


[DMH_AccountCode- 
Digits] 


Include if applicable. 


O 


[DMH_AlternateBilhn 
gDigits] 


• _ _ • _ i _ *r i* ■ i 

Include rf applicable. 


0 


[DMH.BillingDigits] 


Include if applicable. 


o 


[DMH_Redirection- 
Indicator] 


Include if applicable. 


R 


[MobileDirectory- 
Number] 


Include if applicable. 


O 



Example 5 - Successful Qualification Request 

[0032] This operation scenario describes a Qualification Request operation when authorization is confirmed and no 
profile is requested. As shown in step "a" of Fig. 6 t after determining that a roaming MS (not shown) is within its service 
area, a serving MSC 90 sends a QUALREQ message to its VLR 92. The MSC 90 may detect the MS's presence 
through autonomous registration, call origination, call termination (i.e. a page response following a call to the roamer 
port) or a service order. The message, which is otherwise conventional, includes a TSJDataSize parameter in accord- 
ance with the invention, as follows: 



Parameters 


1 Usage 


Type 


MIN 


Served MS MIN 


R 


ESN 


Served MS ESN. 


R 


MSCIO 


Serving MSC MSCID. 


R 


MYTYP 


Serving MSC vendor identification. 


MBC 


QUALCODE 


Type of request = validation only. 


R 


SYSACCTYPE 


Indicates the type of system access. 


R 


TRANSCAP 


Indicates the serving system's transaction capability at the current time. 


R 


TS DataSIze 


Maximum size of Teleservlce payload 


0 



[0033] If the MS had previously registered with the MSC 90 (or any other MSC within the domain of the VLR 92), 
the VLR 92 may take no further action other than to record the identity of the MSC 90 currently serving the MS and 
proceed to step "d" of Fig. 6. If the MS is unknown to the VLR 92, or if the information requested by the MSC 90 is not 
available at the VLR 92, the VLR 92 sends a QUALREQ message to an HLR 94 associated with the MS, as shown in 
step "b" of Fig. 6. The message parameters are the same as in step "a" of Fig. 6, and also include the following additional 
conventional parameters: 



Parameters are as in Step-a, with the following modifications: 


Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



,[0034] In step "c" of Fig. 6, the HLR 94 determines that authorization can be granted to the MS and returns this 
indication to the VLR 92 in a qualreq message, containing the following conventional parameters: 



10 



EP1 117 264 A2 



Parameters 


Usage 


Type 


AUTHPER 


Authorization confirmed indication with period of authorization. 


R 


HLRID [MSCID] 


HLR MSCID to key MS record against for a subsequent 
Un re liable Roam erDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



[0035] In step "d" of Fig. 6, the VLR 92 sends a qualreq message to the MSC 90 containing the same parameters 
as in step "c B of Fig. 6, with the following conventional modifications: 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID. Include if received in Step-c. 


O 


MYTYP 


VLR vendor identification. 


MBC 



Example 6 - Successful RegistrationNotification 

20 [0036] This operation scenario describes a RegistrationNotification operation when confirmed at an HLR. A serving 
MSC determines that a roaming MS is within its service area. The serving MSC may detect the MS's presence through 
autonomous registration, call origination, call termination (i.e., a page response following a call to the roamer port) or 
a service order. As shown in step "a" of Fig. 7, the serving MSC 100 sends a REGNOT message to its VLR 102. The 
message, which is otherwise conventional, contains a TS_DataSize parameter in accordance with the invention, as 



25 


follows: 








Parameters 


Usage 


Type 




IDInfo: 


Set of identification parameters in REGNOT: 




30 


[MIN] 


Served MS MIN. 


R 




[ESN] 


Served MS ESN. 


R 


35 


[MSCID] 


Serving MSC MSCID. 


R 




[PC.SSN] 


Serving MSC PC_SSN. Include if SS7 
carriage services are used. 


O 


40 


[Location ArealD] 


For paging served MS. Include if 
available. 


O 




[System MyTypeC ode] 


Serving MSC vendor identification. 


MBC 


45 


QUALCODE 


Type of qualification required. 


R 




SYSACCTYPE 


Type of system access. 


R 




TRANSCAP 


System's transaction capability 


R 


50 


TERMTYP 


Identifies the radio frequency interface 
standard supported by the associated MS 


R 




AVTYP 


Indicates MS is unavailable for normal call delivery, if applicable. 


O 


55 


SMSADDR 


Temporary routing address of SMS 
subscriber, if applicable. 


O 




Auth Error: 


Parameters included if authentication 
parameters were requested by the 


O 
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(continued) 





Parameters 


Usage 


Type 


5 


[SystemCapabilities] 


Serving MSC but not received from the 
MS: 

Authentication capabilities of serving 
system. 


- 


10 


[ReportType] 


Report of missing authentication 
parameters. 




15 


BORDACC 


Indicates that system access is in a border 
cell, as determined by local procedures. 


O 


TO HfifaCho 

I a uct maize 


Maximum size or i eieservice payioaa 


r\ 
\J 




Access Info: 


Subscriber's access information. Included if system access is in a border cell. 
Includes: 


o 


20 


[ReceivedSignalQuality] 


Raw received signal strength from MS for 
use in multiple access signal strength 
arbitration. 




25 
30 


[ControlChannelData] 
[System AccessData] 


Includes: DCC and CHNO of analog 
access channel for use in multiple access 
detection; 

CM AC for use in signal strength 
arbitration. 

Indicates the Serving MSC and cell site 
for use in multiple access detection. 





35 [0037] The VLR 1 02 determines that either (a) the MS had previously registered with the MSC 1 00 (or another MSC 
within the domain of the VLR) but the MS has been reported inactive by the VLR 102, (b) the MS is not known to the 
VLR 102, or (c) the requested information cannot be made available for the indicated MS. Under these conditions, in 
step "b" of Fig. 7, the VLR 102 forwards the REGNOT message of step "a" of Fig. 7 to an HLR 104 associated with 
the MS, with the following additional conventional parameters: 

40 



arameters 


Usage 


Type 


[PC.SSN] 


Serving VLR PC_SSN. Include if SS7 carriage services are used. 


O 


[MYTYP] 


Serving VLR vendor identification. 


MBC 



45 

[0038] The HLR 104 determines that authorization can be granted to the MS. In step "c" of Fig. 7, it returns the 
requested information to the VLR 102 in a regnot message containing the same parameters as in step N b N of Fig. 7, 
with the following conventional additions and modifications: 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID to key MS record against for a subsequent 
Unreliable Roam erDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



[0039] In step "d" of Fig. 7, the VLR 1 02 forwards the regnot message to the MSC 1 00 using the same parameters 
as in step "c" of Fig. 7, with the following conventional modification: 
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Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



5 

Example 7 - Successful SMSNotrfication 

[0040] This scenario describes the successful use of an SMSNotification operation, conveying to an SMSC the 
SMS_Address of an MS-based Short Message Entity (SME). The invoking Functional Entity (FE) such as an MSC, an 
10 HLR, etc., detects a change of an MS's status or location indicating the availability of an MS-based SME. As shown 
in step "a" of Fig. 8, the invoking FE 1 1 0 may send an SMSNOT message to the responsible SMSC 1 1 2. If the FE 1 1 0 
has a pending request for the address of an MS-based SME, it must respond. The message, which is otherwise con- 
ventional, includes a TS_DataSize parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Used to identify the MS. 


R 


ESN 


Used to identify the MS. 


R 


SMSADDR 


Temporary routing address that can be used to deliver one or more short messages to the 
indicated MS. 


R 


TS DataSize 


Maximum size of Teleservlce pay load 


0 



[0041] As shown in step "b" of Fig. 8, the SMSC 112 confirms the receipt of the address by returning an smsnot 
25 message to the FE 110. 

Example 8 - Successful SMS Request 

[0042] This scenario describes the successful use of an SMS Request operation, resulting in the return of the 
30 SMS_Address of an MS-based SME to an SMSC. As shown in step "a" of Fig. 9, an SMSC 120 does not have the 
current network address of the indicated MS-based SME, and it sends an SMSREQ message toward an HLR 112 
associated with the MS (possibly using SCCP global title translation of the MIN). The message parameters are con- 
ventional: 



Parameters 


Usage 


Type 


MIN 


Used to identify the MS. 


R 


ESN 


Used to identify the MS. 


O 


SMSNOTIND 


Include if a notification of MS availability is not required. 


O 



[0043] If the HLR 122 has the current address of the indicated MS-based SME, an smsreq message in accordance 
with step T of Fig. 9 is sent from the HLR 122 to the SMSC 120. Otherwise, as shown in step "b" of Fig. 9, the HLR 
122 forwards the SMSREQ message toward a VLR 124 serving the addressed MS-based SME. The message param- 
^ eters are the same as in step "a" of Fig. 9. 

[0044] In step V of Fig. 9, the VLR 124 forwards the SMSREQ message toward an MSC 1 26 serving the addressed 
MS-based SME. The parameters are the same as in step "a" of Fig. 9. 

[0045] The MSC 126 returns an smsreq message to the VLR 124 indicating the current network address that can 

be associated with the indicated MS-based SME. The message parameters, which are otherwise conventional, include 

a TS DataSize in accordance with the invention, as follows: 
so ~ 



Parameters 


Usage 


Type 


SMSADDR 


Temporary routing address that can be used to deliver one or more short messages to the 
indicated MS. 


R 


TS DataSize 


Maximum size of Teleservlce pay load 


O 



[0046] In step "e" of Fig. 9, the VLR 1 24 forwards the smsreq message to the HLR 1 22 The parameters are the same 
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as in step "d" of Fig. 9. 

[0047] In step T of Fig. 9, the HLR 122 sends the smsreq to the SMSC 120. The parameters are the same as in 
step "d" of Fig. 9. 

5 Example 9 - Successful TransferToNumberRequest 

[0048] This operation scenario describes a normal TransferToNumberRequest operation. As shown in step "a" of 
Fig. 10, an originating MSC 130 sends a TRANUMREQ message to an HLR 132 associated with an MS (not shown), 
including an indication of the feature responsible for redirecting the call (e.g., CFB). The message parameters, which 
10 are otherwise conventional, include a TS_DataSize parameter in accordance with the invention, as follows: 



15 



20 



25 



30 



Parameters 


Usage 


Type 


BILLID 


Originating BillingID, required to identify instances of Flexible Alerting 




MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCIN 


Include for IS-41-Cox later. 


O 


MYTYP 


Originating MSC vendor identification. 


MBC 


REDREASON 


Identifies reason for the TRANUMREQ. 


R 


TRANSCAP 


Indicates the originating system's transaction capability at the current time. 


R 


GRPINFO 


Information associated with group routing. Include if available 


O 


LEGINFO 


Identifies a leg in a multiple termination call. Include if available. 


O 


TS DataStze 


Maximum size of Teleservlce payload 


O 


As shown in step "b" of Fig. 10, the HLR 130 determines the forward-to number for redirecting the cs 
> this to the MSC 130 in a tranumreq message. The parameters of this message are as follows: 





Parameters 


Usage 


Type 


35 


Routing Info: 
[TerminationList 


Call routing information: 
Network termination information. 
Include if TerminationList is allowed. 


O 


40 


[Digits(Destination] 


PSTN DN for use in call routing. 
Include if TerminationList is not 
allowed. 


O 


45 


[Digits(Carrier)] 


Called subscriber's PIC. Include if 
applicable and if not specified within 
the TerminationList parameter. 


O 


ACTCODE 


Include if action to be performed is not 
implied through presence of other 
parameters. 


O 


50 


ANN LIST 


List of tones or announcements to play. If 
not included, announcement is based 
on other parameters in response. 


O 


55 


TERMTRIG 


Termination trigger points currently 
active for the subscriber. Include if 
applicable. 


O 




GRPINFO 


Identifies the new leg in a multiple 


O 
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(continued) 





Parameters 


Usage 


Type 






termination call. Include if applicable. 




5 


CNIinfoASCII: 


CNI information including digits 
parameters in ASCII format. Include 
as applicable: 




10 


[CallingPartyNumber- 
Stringl] 


Calling number digits (network- 
provided), incl. Presentation restriction 
information. 


O 


15 


[C ailing Party Number- 
String2] 


Calling number digits (user-provided), 
incl. Presentation restriction 
information. 


0 


20 


[RedirectingNumber- 
String] 


Redirecting number digits, inci. 
Presentation restriction information. 


0 


25 


[CallingPartySubaddress] 
[RedirectingSubaddress] 


Calling number subaddress (user- 
provided). 

Redirecting number subaddress. 0 


O 






Q oH i rckoti n n ni imhor Hirtrtc in R/^Pi fnrmat 
ntsuiicwLiny iiuiiilfci uiyiio m Dvu luiiiidi. 

May include if call is to be redirected 
out of the Originating MSC. 


KJ 


30 


DM H Data: 


Data for DMH recording purposes: 






[DMH_AccountCode- 
Digits] 


Include if applicable. 


o 


35 


[DMH_AltemateBilling- 
Digrts] 


Include if applicable. 


o 




[DMH_BillingDigits] 


Include if applicable. 


o 


40 


[DMH_Redirection- 


Reason for extending the incoming call. 


R 


45 


Indtcator] 

[MobileDirectory- 
N umber] 


Include for recording purposes. 
Include if applicable. 


O 



[0050] Accordingly, a system and method have been described for providing an indication of maximum teleservice 
payload size in a wireless communication system. While various embodiments of the invention have been disclosed, 
ft should be apparent that many variations and alternative embodiments could be implemented in accordance with the 
invention. It is understood, therefore, that the invention is not to be in any way limited except in accordance with the 
spirit of the appended claims and their equivalents. 



Claims 

55 

1 . A method for providing improved teleservice messaging to a mobile station in a wireless communication network, 
comprising the steps of: 
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receiving at a network sending entity an indication of the maximum teleservice payload size that can be sent 
by said network sending entity to said mobile station via network receiving entities serving said mobile station; 
and 

s utilizing said payload size indication at said network sending entity to format the size of teleservice messages 

sent by said network sending entity to said mobile station via said network receiving entities. 

2. A method in accordance with Claim 1 wherein said step includes receiving said payload size indication from one 
of said network receiving entities at said network sending entity. 

10 

3. A method in accordance with Claim 2 wherein said network receiving entity from which said payload size indication 
is received is a switch serving said mobile station. 

4. A method in accordance with Claim 3 wherein said switch is a Mobile Switching Center (MSC). 

15 

5. A method in accordance with Claim 3 wherein said switch is a Mobile Data Intermediate System (MDIS). 

6. A method in accordance with Claim 3 wherein said switch is a Serving GPRS Support Node (SGSN). 

20 7. A method in accordance with Claim 2 wherein said receiving step farther includes receiving said payload size 
indication from one of said network receiving entities to at said network sending entity via a database associated 
with said mobile station. 

8. A method in accordance with Claim 7 wherein said database is a Home Location Register (HLR). 

25 

9. A method in accordance with Claim 1 further including preliminarily receiving said payload size indication at a 
database associated with said mobile station as a message parameter during standard registration message ex- 
change between one of said network receiving entities and said database during operations of said wireless net- 
work, said preliminary receiving step being performed prior to said receiving step. 

30 

10. A method in accordance with Claim 9 wherein said receiving step further includes receiving said payload size 
indication from said database at said network sending entity as a message parameter during standard registration 
message exchange between said database and said network sending entity. 

35 1 1 . A method for providing improved teleservice messaging to a mobile station in a wireless communication network, 
comprising the steps of: 

providing to a network sending entity an indication of the maximum tele service payload size that can be sent 
by said network sending entity to said mobile station via network receiving entities serving said mobile station; 
40 and 

said maximum teleservice payload size indication being utilizable by said sending network entity to format the 
size of teleservice messages sent by said network sending entity to said mobile station via said network re- 
ceiving entities. 

45 

12. A method in accordance with Claim/I wherein said providing step includes providing said payload size indication 
from one of said network receiving entities to said network sending entity. 

13. A method in accordance with Claim 12 wherein said network receiving entity providing said payload size indication 
so is received is a switch serving said mobile station. 

14. A method in accordance with Claim 13 wherein said switch is a Mobile Switching Center (MSC). 

15. A method in accordance with Claim 13 wherein said switch is a Mobile Data Intermediate System (MDIS). 

55 

16. A method in accordance with Claim 13 wherein said switch is a Serving GPRS Support Node (SGSN). 

17. A method in accordance with Claiml2 wherein said providing step further includes providing said payload size 
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indication from one of said network receiving entities at said network sending entity via a database associated with 
said mobile station. 

A method in accordance with Claim 17 wherein said database is a Home Location Register (HLR). 

A method in accordance with Claim 1 1 wherein said providing step includes providing said payload size indication 
to a database associated with said mobile station as a message parameter during standard registration message 
exchange between one of said network receiving entities and said database during operations of said wireless 
network. 

A method in accordance with Claim 9 wherein said providing step further includes providing said payload size 
indication from said database to said network sending entity as a message parameter during standard registration 
message exchange between said database and said network sending entity. 

A system for providing improved teleservice messaging to a mobile station in a wireless communication network, 
comprising means for carrying out the steps of a method as claimed in any of the preceding claims. 



20 
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FIG. 1 
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FIG. 2 
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FIG. 7 
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